Clarify header protection sampling #4404
Conversation
The Header Protection Sample process operates on the ciphertext only, but the current description in section 5.4.2 explains it headers included, which is a bit confusing. This explicitly specifies the `packet` variable used in pseudocodes is with headers included. Signed-off-by: Paul Mabileau <paulmabileau@hotmail.fr>
Header protection sampling operates on ciphertext, therefore it is possible to explain it relative to the ciphertext only, without any form of headers involved. This commit proposes just that, with a pseudocode included. Signed-off-by: Paul Mabileau <paulmabileau@hotmail.fr>
janaiyengar
added
the
editorial
|
Any news? |
|
We typically have the high-level discussion on such things in an issue first, and if that seems to get consensus, a PR is opened. We don't have to do that for this one, I'll start tracking it as if it were an issue and hopefully you'll get feedback, but please remember for the future. |
|
Since our project board isn't set up for tracking PRs alongside issues, I opened #4435 . |
@larseggert Sorry I missed this in the contributing guidelines... In the future, if I open an issue explaining such a suggestion for example, could I then propose a PR right after in order to show more precisely what I intend, or should I still wait for consensus first? |
|
Your call. I'd personally wait for a bit with a PR, just to avoid wasting work if the issue doesn't get traction. |
|
Alright, thanks! |
|
Thanks for suggesting this Paul. I wasn't smart enough to see what was needed, but @kazuho was and I think we have a much clearer document as a result. |
Hello gentlemen!
The header protection sampling (HPS) is quite simple, as it is just selecting 16 bytes out of the encrypted payload, but we think the current description is really confusing.
Indeed, section 5.4.2 explains the process with pseudocodes computing an offset relative to the beginning of an entire packet which payload is the encrypted one. However, when applying the AEAD function, one cannot do it in-place, so additional allocation must be reserved in any case. Therefore, one most probably has access to the encrypted payload separately from the unprotected packet, headers and payload.
Thus, this PR proposes two things, split in different commits:
We have not changed or removed any existing content however, as we believe this draft could use some more explanations and clarifications here and there, rather than less with confusing elements, even if it means a bit of duplication.
Please tell us if there is any form of typo, wrong wording, grammatical issue or just general mistake, especially concerning the new pseudocode.
Hope this helps.
Cheers,
Paul.